查看原文
其他

如何进行容器管理平台监控(k8s)| 运维进阶

twt社区 twt企业IT社区 2022-07-03
随着容器化、分布式的不断发展,业务系统的逻辑变得复杂,定位问题越来越困难,就需要从宿主机、容器管理平台和容器应用等多个层面进行监控,才可以定位性能问题、异常问题、安全问题等。本文介绍容器管理平台(k8s)的监控方法。

如果您想系统学习容器的监控及优化,了解相关监控组件如何选型、如何搭建、如何识别存在问题的组件、定位问题根本原因、快速解决问题等。请看文后介绍。

李志伟,证通股份有限公司系统架构师。10多年金融行业IT工作经验,2年开发工作经验,5年多IT运维工作经验,3年容器及微服务项目经验。有着丰富的大型系统交付和维护工作经验,丰富的数据中心级故障场景切换及问题定位经验。


监控方式

容器类监控一般采用Prometheus进行监控,支持默认的pull模式获取数据,这也是官方推荐的方式。但是如果一些网络或防火墙等原因无法直接pull到数据的情况,就要借助Pushgateway让Prometheus转换为push方式获取数据;又比如我们将prometheus搭建在外网去监控内网应用的情况下,由于内网有诸多安全限制使得无法穿透,这时就要借助push模式来解决问题,还有就是监控的轮询监控大于被监控程序的执行时间,比如5秒pull一次数据,但是被监控程序1秒就执行完了。如下为pull和push的通用比较:

Pull

实时性取决于定时任务;客户端是有状态,需要知道拉取点,服务器端无状态,通常是短连接;难点实时性和流量的取舍。

Push

实时性较好;客户端无状态,服务器端有状态,需要了解每个客户端的推送点;通常是长链接;难点客户端能力和push能力不匹配问题。


K8s集群监控

使用系统命令查看kubectl top pod --all-namespaces

使用prometheus查询语句

sum(kube_pod_container_resource_limits{resource="cpu", unit="core",namespace="$Namespace"})

CPU usage / available CPU in cluster

sum (rate (container_cpu_usage_seconds_total{namespace="$Namespace"}[1m])) / sum(machine_cpu_cores) * 100

Kube_namespaces_cpu_used_percent >80%

Kube_namespaces_memory_memused_bytes_percebt>80%

Kube_namespaces_requests_cpu_percent>80%

Kube_namespaces_requests_memory_percent>80%

Pod监控项

资源限制

spec:

containers:

- image: gcr.io/google_containers/serve_hostname

  imagePullPolicy: Always

  name: kubernetes-serve-hostname

  resources:

    limits:

      cpu: "1"

      memory: 512Mi

    requests:

      cpu: "1"

      memory: 512Mi

Pod Metrics

监控项举例:

Kube_pod_container_limit_cpu_cores>2

Node节点监控及告警

命令Kubectl get nodes

连续5分钟node状态是非ready,与master节点失联,最大告警2次

先检查状态

Systemctl status kubelet

Systemctl restart kubelet

守护进程(daemonset)监控

Kube_daemonset_statsu_number_unavailable>0 不可用pod数大于0

Kube_daemonset_current_number_normal==0 daemonset的pod与期望

Kube_daemonset_updated_number_normal==0 daemonset已更新与期望

守护进程监控项

无状态应用监控

Kube_deployment_status_replicas_unavailable>0 不可用副本数大于0

Kube_deployment_current_replicas_normal==0 当前副本数与期待副本数不一致

Kube_deployment_updated_replicas_normal==0 updateed副本数与期望副本数不一致。

Kubectl get deploy busybox

有状态应用监控

有状态核心告警

Kube_statefulset_replicas_ready_normal==0 副本是否与期望副本一致

Kube_statefulset_replicas_current_normal==0 当前副本与期望

查看未正常运行的pod的状态和事件,查看kubeclt deploy状态和事件

负载均衡器监控

应用访问通过ingress controller转发到ingress,再转发到具体的服务,最后转到具体的pod。因此ingress 监控至关重要。

URL、源IP、UserAgent、状态码、入流量、出流量、响应时间等,从这些信息中,我们能够分析出非常多的信息,例如:

1.网站访问的PV、UV;

2.网站访问的错误比例;

3.后端服务的响应延迟;

4.不同URL访问分布。

主要监控指标:

监控metric

事件监控

事件监控是Kubernetes中的另一种监控方式,可以弥补资源监控在实时性、准确性和场景上的缺欠。

Kubernetes的架构设计是基于状态机的,不同的状态之间进行转换则会生成相应的事件,正常的状态之间转

换会生成Normal等级的事件,正常状态与异常状态之间的转换会生成Warning等级的事件。通过获取事件,实时诊断集群的异常与问题。

Pod常见问题列表:

  • ImagePullBackOff

  • CrashLoopBackOff

  • RunContainerError

  • 处于Pending状态的Pod

  • 处于未就绪状态的Pod

ImagePullBackOff

当Kubernetes无法获取到Pod中某个容器的镜像时,将出现此错误。

可能原因:

  • 镜像名称无效,例如拼错镜像名称,或者镜像不存在。

  • 您为image指定了不存在的标签。

  • 您检索的镜像是私有registry,而Kubernetes没有凭据可以访问它。

解决方法:

  • 前两种情况可以通过修改镜像名称和标记来解决该问题。

  • 第三种情况,您需要将私有registry的访问凭证,通过Secret添加到Kubernetes中并在Pod中引用它。

CrashLoopBackOff

如果容器无法启动,则Kubernetes将显示错误状态为:CrashLoopBackOff。

可能原因:

  • 应用程序中存在错误,导致无法启动。

  • 未正确配置容器。

  • Liveness探针失败太多次。

解决方法:

  • 您可以尝试从该容器中检索日志以调查其失败的原因。如果容器重新启动太快而看不到日志,则可以使用命令:$ kubectl logs <pod-name>--previous。

RunContainerError

当容器无法启动时,出现此错误。

可能原因:

  • 挂载不存在的卷,例如ConfigMap或Secrets。

  • 将只读卷安装为可读写。

解决方法:

  • 请使用kubectl describe pod命令收集和分析错误。

处于Pending状态的Pod

当创建应用时,在变更记录中该Pod一直Pending状态。

可能原因:

  • 集群没有足够的资源(例如CPU和内存)来运行Pod。

  • 当前的命名空间具有ResourceQuota对象,创建Pod将使命名空间超过配额。

  • 该Pod绑定到一个处于pending状态的PersistentVolumeClaim。

解决方法:

  • 检查$ kubectl describe pod<pod name>命令输出的“事件”部分内容或者在控制台查看应用事件。

  • 对于因ResourceQuotas而导致的错误,可以使用$ kubectl get events--sort-by=.metadata.cre-ationTimestamp命令检查集群的日志。

处于未就绪状态的Pod

如果Pod正在运行但未就绪(not ready),则表示readiness就绪探针失败。

可能原因:

  • 当“就绪”探针失败时,Pod未连接到服务,并且没有流量转发到该实例。

解决方法:

  • 就绪探针失败是应用程序的特定错误,请检查$ kubectl describe pod<pod name>命令输出的“事件”部分内容,或者在控制台查看对应的应用事件。

监控指标阈值

推荐值

觉得本文有用,请转发或点击“在看”,让更多同行看到


本文同时也是以下课程中的第2章节,如果您想系统学习相关知识技能,可以点击阅读原文下载学习此课程。学习中有相关问题,可以持续到此辅导活动中提问,有专家解答:云计算工程师容器云平台的部署、监控和实施在线辅导答疑 (点击可了解详情和参与)


课程名称:《容器的监控及优化》课程出品人:李志伟,证通股份有限公司,系统架构师。10多年金融行业IT工作经验,2年开发工作经验,5年多IT运维工作经验,3年容器及微服务项目经验。有着丰富的大型系统交付和维护工作经验,丰富的数据中心级故障场景切换及问题定位经验,丰富的IBM产品和开源产品的运维和故障诊断经验,从事过银行、证券、政府、大企业的IT系统双活建设和维护工作。项目中主要承担项目负责人,规划设计,技术专家等职责,负责推动重大方案的输出、审核以及交付工作。2020 容器云职业技能大赛百位专家委员会成员。课程简介:随着容器化、分布式的不断发展,业务系统的逻辑变得复杂,定位问题越来越困难,就需要从宿主机、容器管理平台和容器应用等多个层面进行监控,才可以定位性能问题、异常问题、安全问题等。通过学习如下内容可以了解相关监控组件如何选型、如何搭建、如何识别存在问题的组件、定位问题根本原因、快速解决问题等。课程内容:

监控方式

Pull

Push

容器管理平台监控(k8s)

K8s集群监控

Pod监控项

Node节点监控及告警

守护进程(daemonset)监控

无状态应用监控

有状态应用监控

负载均衡器监控

事件监控

监控指标阈值

主机资源监控

初始Node Exporter监控指标

从Node Exporter收集监控数据

容器资源监控

cAdvisor与Prometheus集成

CPU使用率

内存

网络

磁盘

中间件监控

Tomcat

Wildfly

监控Redis集群

监控mysql数据库

链路监控

zipkin简介

Jaeger概述

Istio Trace链路追踪方案

非java类监控

黑盒监控

高可用推荐方案

Prometheus联邦集群

Thanos

K8s监控优化举例

四个黄金信号

USE 方法

RED 方法

CPU饱和率

内存利用率

内存饱和度

k8s Apiserver 指标分析

如何优化k8s

联动分析举例

应用异常分析举例

K8s性能监控及优化举例


此课程属于“2020 容器云职业技能大赛运维技术岗课程系列”,是针对“2020 容器云职业技能大赛”(大赛详情请点击此处了解>>>)专门打造的精品课程,课程体系如下:

课程1:容器云平台的部署、监控和实施

容器云平台的集群高可用安装部署、配置

容器的部署

容器的监控、优化

K8S/OpenShift部署、监控

容器镜像仓库的运维管理

Ansible运维管理平台部署、维护、调优

Saltstack运维管理平台部署、维护、调优

DevOps工作流部署k8s容器化应用程序

日志管理开发和部署及配置

容器云架构整体设计

课程2:容器云平台系统调优、提升系统性能

容器云平台的巡检容器云平台的性能瓶颈定位容器的监控、优化容器云平台的性能优化容器云平台日常故障处理

课程3:容器云平台日常系统运维

容器镜像仓库的运维管理Ansible运维管理平台部署、维护、调优Saltstack运维管理平台部署、维护、调优DevOps工作流部署k8s容器化应用程序日志管理开发和部署及配置CI/CD 自动化流水线 pipeline维护、开发源代码审查 rules 定义等自动化测试场景开发等容器云对接容器资源池的安全合规接口、对接服务等调研资产/配置/容量管理数据安全输出服务协议及接口开发
红色标题课程目前已发布上线识别二维码即可前往下载学习还可以进行自测考试完成所有课程及自测可获得岗位结业证书


了解更多”2020年容器云职业技能大赛“信息:



下载 twt 社区客户端 APP


长按识别二维码即可下载

或到应用商店搜索“twt”


长按二维码关注公众号

*本公众号所发布内容仅代表作者观点,不代表社区立场

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存